Field programmable gate arrays (FPGAs) are commonly used to implement custom logic in hardware, but current technology FPGAs have a maximum clock rate of about 390 MHz. When FPGAs are used in high-speed network testing equipment, the maximum line rate that this test equipment can handle can be approximated by the equation:bus width×FPGA clock frequency=maximum line rate  (1)For 32 byte (256 bit) buses and 390 MHz clock frequency, the maximum line rate that an FPGA can support is 100 gigabits per second. Although network speeds are increasing, FPGA maximum clock rates are not, which means that, in order to accommodate faster network speeds, network testing equipment must use wider buses. For example, to support 400 gigabits per second line rates, an FPGA having a clock frequency of 390 MHz must use a bus that is 128 bytes (1024 bits) wide.
However, there are disadvantages to using wider buses. One disadvantage is that the FPGA may be processing multiple packets at the same time. As used herein, the terms “packet” and “frame” refer to a collection of data for which its own CRC must be generated. As such, the terms “frame” and “packet” will be used synonymously herein. Even in a pipelined architecture, data from multiple packets may need to be processed during the same clock cycle. Further complicating the process is the fact that the size of each packet may vary. For example, assuming that the minimum frame size is 64 bytes, it is now possible that the FPGA may be processing the end of a first frame, a complete second frame, and the beginning of a third frame during the same clock cycle. This means that the FPGA will need to complete a CRC calculation for the first frame's data, perform an entire CRC calculation for the second frame's data, and begin CRC calculation for the third frame's data simultaneously.
One approach to performing these steps would be to use a single CRC calculation engine and feed that CRC engine the data from the first frame, followed by the data from the second frame, and finally the data from the third frame. This would allow the use of minimum hardware but would be prohibitively time consuming. Another approach would be to have multiple instances of a CRC engine that operates on 64 bytes at a time, but this approach is expensive from a hardware standpoint as well as inefficient, since in most cases only one or perhaps two of the CRC engines would be necessary—the third CRC engine being required only in the scenario described above, in which data from three separate frames is being processed. What is desired is an approach that provides maximum flexibility and performance with minimum hardware cost.
Accordingly, in light of these disadvantages associated with using an FPGA to process multiple frames of data simultaneously, there exists a need for methods, systems, and computer readable media for a multi-packet CRC engine.